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In this report we introduce the C++ design pattern called “Sandwich Pattern” . This design 
pattern is a variation of plain static polymorphism to statically replace certain static and 
dynamic characteristics of a data type while keeping certain other characteristics unchanged. 
This design pattern is for example applied in the pe rigid multibody physics engine to statically 
adapt rigid bodies and contacts between these bodies to specific algorithms that are selected 
at compile time. 


1 Motivation 

In certain situations during code development the necessity arises to customize a type depending on a 
certain configuration. It may be necessary to completely replace certain member data and functions of 
the type, where other parts should remain a permanent component of the type. It may even be necessary 
to replace a set of virtual functions by a different set of virtual functions to accommodate for a different 
configuration. 

One of these situations was encountered for the implementation of a RigidBody class that represents 
the base for all kinds of rigid, completely undeformable bodies within a framework for the simulation of 
such rigid bodies. Depending on a set of statically selected algorithms working with the RigidBody type, 
certain member data and functions of the RigidBody class should be customizable, whereas other com- 
ponents should not be interchangeable. Imagine, that all of these algorithms pose different requirements 
on the rigid body data structure. Each algorithm requires different, individual data members within each 
rigid body in order to be able to optimally perform its task. Additionally, each algorithm requires a 
certain set of special functions to perform specific tasks or just to access the individual data members. 
Therefore the question arises how to implemented the basic rigid body data structures to accommodate all 
requirements for the current algorithms and all future algorithms with yet unknown requirements that will 
have to be integrated into the rigid body framework. Due to the real-time demands of certain simulation 
scenarios, these data structures additionally have to be suited for high performance computing, i.e., the 
data structures themselves should not be too costly in terms of performance. 

For the remainder of this report, we will use this RigidBody class to illustrate the development of a very 
flexible design pattern called the “Sandwich Pattern” . This C++ design pattern in its basic form allows 
to statically change certain characteristics (member data and functions) of a data type while keeping 
certain others unchanged by a clever combination of static and dynamic polymorphism. In Section 2 we 
will first introduce the general idea of this design pattern by means of the RigidBody class. Section 3 
will introduce the hierarchical application of this pattern that in particular allows to statically change 
the dynamic characteristics of the data type, i.e., to customize the set of available virtual functions. To 


demonstrate the design pattern Section 4 will show an excerpt of the implementation of the Sandwich 
Pattern as realized in the pe rigid multibody physics engine. Section 5 will conclude the report. 


2 The Sandwich Pattern 

A first naive approach to solve the problem would be to add all according necessary data and (virtual) 
function members to the RigidBody base class: 

Listing 1| Naive approach to integrate the requirements of numerous algorithms into the RigidBody class 

1 class RigidBody 

2 { 

3 private: 

4 // Data members for algorithm 1 

5 // Data members for algorithm 2 

6 II ... 

8 // Private (virtual) functions for algorithm 1 

9 // Private (virtual) functions for algorithm 2 

o II ... 

2 public : 

3 // Public (virtual) functions for algorithm 1 

4 // Public (virtual) functions for algorithm 2 


This data structure would certainly only result in negligible performance penalties. However, obviously 
this approach leads to a bloated RigidBody base class, both in terms of available functionality as well 
as in terms of the memory footprint of a RigidBody object. All data members of every algorithm are 
constantly available, although only one algorithm of each category is active at a time. In fact, in our 
case the configuration consisting of a certain set of algorithms is selected at compile time since switching 
between the algorithms only very rarely makes sense (for instance because either real-time aspects or 
physical accuracy aspects are predominant aspects). 

One approach to solve customization problems is the use of static polymorphism via the C-H- template 
mechanism: 


Listing 2: Template-based implementation of the RigidBody class 

1 template < typename C > // Type of the configuration 

2 class RigidBody 

3 { 

4 private: 

5 // Conf igurat ion -specif ic data members 

6 II ... 

8 // Conf igurat ion -specif ic private (virtual) functions 

9 II ... 

2 // Configuration-specific public (virtual) functions 

3 II ... 


With this approach it is possible to specifically add the required data and (virtual) function members 
to the RigidBody class depending on the type of the configuration (that represents the set of selected 
algorithms). Additionally, there is no performance penalty involved in this design. However, the downside 
of this approach is obvious: Since every specialization of the RigidBody class template, which adapts 
the type to the requirement of a specific configuration/algorithm, additionally needs to define the set of 
permanent members that should be a constant part of all rigid bodies, the implementation overhead of 
each specialization might be substantial. Depending on the complexity of the base class, this might very 
well involve several thousand lines of code that have to be rewritten for every single specialization, i.e., 
for every new algorithm. However, a simple extension based on dynamic polymorphism improves the 
situation considerably: 


RigidBody 



private : 

// Common data members for all rigid bodies 

u ... 

II Common private (virtual) functions for all rigid bodies 

II ... 

public: 

// Common public (virtual) functions for all rigid bodies 

II ... 


template< typename C > II Type of the configuration 
class RigidBody : public RigidBodyBase 

i 

private : 

// Conf igurat ion -specif ic data members 

II ... 

II Conf igurat ion - specif ic private (virtual) functions 

II ... 

public: 

// Conf igurat ion -specif ic public (virtual) functions 

II ... 


Due to this refactoring via the introduction of the RigidBodyBase class which now contains all common 
functionality for all rigid bodies, the RigidBody class template has only to implement the configuration- 
specific data and (virtual 1 ) function members that are required by the selected algorithms. Additionally, 
even due to the addition of the RigidBodyBase class, no additional performance bottleneck is introduced 
in the design. Therefore apart from some minor criticisms about this design 2 this approach is already 
well suited for the requirements on the RigidBody data structure. However, one additional improvement 
can still be done. Certain common aspects of the data type to be customized might not fit into the new 
base class, but should remain in the top level class. Therefore, in addition to the RigidBodyBase class 
we introduce another class that will represent the top level class of this hierarchy and we will additionally 
slightly adjust the names of the classes: 

Listing 4: Application of the Sandwich Pattern to the RigidBody base class 
typedef /* ... */ Config; 



// Common data members for all rigid bodies 

II ... 

II Common private (virtual) functions for all rigid bodies 

II ... 

public: 

// Common public (virtual) functions for all rigid bodies 

II ... 


template< typename C > II Type of the configuration 
class RigidBodyTrait : public RigidBodyBase 

f 

private : 

// Conf igurat ion - specif ic data members 

II ... 

II Conf igurat ion - specif ic private (virtual) functions 

II ... 


1 We will see t 

2 See [5] for a 


public: 

// Conf iguration -specif ic public (virtual) functions 

n ... 



// Top level common data members for all rigid bodies 

II ... 

II Top level common private (virtual) functions for all rigid bodies 

II ... 

public: 

// Top level common public (virtual) functions for all rigid bodies 

II ... 


In this class hierarchy the Sandwich Pattern is already fully realized. The RigidBodyBase class contains 
all data members and (virtual) functions common to all rigid bodies. On top of that the RigidBodyTrait 
class provides all configuration-specific data and functionality of the rigid bodies. The top level RigidBody 
class contains all common top level data and functionality that (either logically or from an implementa- 
tional point of view) cannot be moved to the RigidBodyBase class. Note that the RigidBody class publicly 
derives from a specific instantiation of the RigidBodyTrait class template according to a configuration 
Conf ig that is specified at compile time. 



Figure 1: Application of the sandwich pattern to the RigidBody base class. 

With Figure 1 it becomes obvious that the Sandwich Pattern is a variant of plain static polymorphism. 
Instead of defining a single class template that would have to carry the burden to redefine common func- 
tionality with every specialization, two additional classes are defined, one as the base class of the center 
customization class, and one as the top level class. All three classes build a logical compound and still 
represent the original RigidBody class, but offer a much more convenient way to adapt the class to specific 
settings. Especially, specializing for a particular algorithm requires much less programming effort than 
the single template class. 

Although the scheme fulfills all requirements on the RigidBody data structure, several potential disad- 
vantages of the Sandwich Pattern should be discussed. One disadvantage in term of performance might 
be the additional overhead due to two more constructor and destructor calls during the construction and 
destruction of a type using this design pattern. Whether or not this results in a real performance bottle- 
neck strongly depends on the type of applications the type is involved in. In case such types are frequently 
created and destroyed and in case the additional function calls are expensive, the performance penalty 
might be measurable. However, if either construction/destruction is a rare event (as it is for example 
in rigid body simulations) or in case the constructors and (non-virtual) destructors can be inlined these 
additional function calls will not be a performance issue. Another disadvantage is the increased depth 
of the class hierarchy, which is usually considered bad in class design (for a thorough discussion on this 
topic see [1]). However, in this case the three classes build a logical, inseparable unit, i.e. they represent 
a single class and are only refactored into three classes for implementation reasons. Therefore, this design 
arguably does not increase the depth of the class hierarchy. 

Another disadvantage from a class design point of view is the potential misuse of the “internal” classes 
(in this example the RigidBodyBase and RigidBodyTrait class). It is for instance possible to derive 
other classes from one of these two internal classes since there is no general protection against inheri- 


tance. However, in this case one has to distinguish between “protecting against Murphy, versus protecting 
against Machiavelli” [2]. However, whereas the intentional misuse cannot be prevented (Machiavelli), the 
accidental misuse via inheritance is rather improbable (Murphy). 

The most important drawback of this design pattern, however, are its implications to the rest of the 
implementation that uses the customized types. Every functionality that uses an algorithm-specific char- 
acteristic of the data type has to be transformed into a template, too. This is in particular true for all 
algorithms using the RigidBody class, since the customized traits classes provide the functionality for these 
algorithms. Since certain characteristics (as for instance functions) might be completely replaced, using 
these characteristics even in case a different instance of a trait class is selected will result in compiler errors. 
Assuming that a class called Algorithm expects a RigidBody to have a function called doSomething, the 
following example illustrates this problem: 

Listing 5: Non-template implementation of Algorithm 

1 class Algorithm 

2 { 

3 public: 

4 II ... 

5 void runAlgor ithm ( RigidBody* body ) 

6 { 

7 II... 

s body->doSomething() ; // <- This might result in an error even if Algorithm 

9 II is not selected 


// 


The code in Listing 5 will only compile, if the according traits classes are selected that provide the 
rigid bodies with the configuration-dependent function doSomething. In case a different configuration is 
selected, the compiler will flag this as an error, since it is possible to determine that a rigid body does not 
have the required function. Therefore, the use of these custom characteristics has to be hidden before the 
compiler by use of template argument dependent types. The simplest approach in this example would be 
to pass the type of rigid bodies as template arguments: 


Listing 6: Template-based implementation of Algorithm 


1 template < typem 

2 class Algorithm 

3 { 

5 II ... 

6 void runAlgoi 

7 { 

8 II ... 

9 body->doS< 

1 II ... 

2 > 

3 II ... 


ie BodyType > 


•ithm( BodyType : 


// 

II 


II Type of the rigid bodies 


<- This will always compile : 
function call is deferred 


the check for 
Algorithm is 


a valid 


In this case, the compiler has to defer the evaluation of the correctness of the function call until the 
type of the rigid body is known. In case the Algorithm class is not selected, this therefore does not result 
in an error anymore. 

The severity of this disadvantage completely lies in the eye of the beholder. Depending on the situation, 
it might be considered a minor inconvenience or might even lead to an immediate rejection of the design 
pattern. Whether or not the Sandwich Pattern can be applied in a certain situation is therefore completely 
depending on the actual problem. 

3 The Hierarchical Sandwich Pattern 

It is obviously also possible to apply the Sandwich Pattern on several levels of a class hierarchy. For 
instance, the design pattern could also be applied to classes deriving from the RigidBody class. Let’s 


assume that the Sphere class represents a spherical rigid body and derives publicly from the RigidBody 
class. By applying the Sandwich Pattern, the implementation of the original Sphere class would be 
refactored as following: 


Listing 7 : Application of the Sandwich Pattern to classes derived from RigidBody 

1 typedef /* customization type */ Config; 

3 II ... The classes RigidBodyBase , RigidBodyTrait , and RigidBody are implemented as before 

5 class SphereBase : public RigidBody 

6 { 

7 private: 

8 // Common sphere - specif ic private data members and functions 

9 // Sphere - specif ic implementation of private virtual functions 

2 //Common sphere - specif ic public functions 

3 // Sphere - specif ic implementation of public virtual functions 


is template < typename C > // Type of the configuration 

17 class SphereTrait : public SphereBase 

18 { 

20 // Conf igur at ion - specif ic private sphere data members and functions 

21 // Implementation of conf igur at ion - specif ic private virtual functions 

23 public: 

24 // Conf igurat ion -specif ic sphere public functions 

25 II Implementation of conf igur at ion - specif ic public virtual functions 


28 class Sphere : public SphereTrait <Conf ig > 

29 { 

31 // Top-level sphere - specif ic private data members and functions 

33 public: 

34 II Top-level sphere - specif ic public functions 


In case the Sandwich Pattern is applied in this way, it is not only possible to change certain static 
characteristics of a type (i.e., replace a certain set of member data and functions), but it is also possible 
to customize the dynamic characteristics of the type by completely replacing a set of virtual functions 
by another set. Depending on the configuration, each specialization of the RigidBodyTrait class can 
individually define a certain number of virtual functions, that are implemented in the according trait 
class of the derived class depending on the characteristics of both the derived type and the configuration. 
Figure 2 gives an impression of the hierarchical application of the Sandwich Pattern to a class hierarchy 
based on the RigidBody base class: 



Figure 2: Hierarchical application of the Sandwich Pattern to the class hierarchy based on the RigidBody class. 



Figure 3: Impressions of pe simulations from small-scale scenarios with only several bodies to large-scale simula- 
tions involving millions of interacting rigid bodies. 


4 Application of the Sandwich Pattern in the pe Physics Engine 

The pe rigid multibody physics engine is a C-| — b framework for the simulation of rigid, completely unde- 
formable bodies (for more information on pe see [4, 3]). One of the major goals of this framework is to 
provide a large selection of different algorithms for all phases of a time step in the rigid body simulation. 
This includes different algorithms for 

(a) the (coarse and fine) collision detection phase, 

(b) the contact grouping (batch generation) phase, and 

(c) the collision resolution phase. 

The algorithms in each category differ in the way they address the different problems. For instance, 
for certain simulations it is important to resolve collisions as physically accurate as possible whereas in 
other simulations the real-time characteristics of the algorithms (i.e. the fast but less accurate processing 
of collisions) are the crucial requirement. It can be easily seen that therefore the requirements on the 
RigidBody data structure changes depending on which algorithm is selected. The selection of the different 
algorithms happens in a configuration file: 

Listing 8: Compile time selection of rigid body algorithms 

1 #def ine pe_COARSE_COLLIS ION.DETECTOR pe :: detection :: coarse :: HashGr ids 

2 #def ine pe_FINE_COLLISION_DETECTOR pe :: detection :: fine :: MaxContacts 

3 #def ine pe_BATCH_GENERATOR pe :: batches :: UnionFind 

4 #def ine pe_ CONTACT. SOLVER pe :: response :: FFDSolver 


For all four categories, an algorithm has to be defined. For instance, the FFDSolver is for this example 
the selected contact solving algorithm. The selection of all algorithms is combined via the Configuration 
class to the compile time configuration Conf ig, which is used to instantiate all traits classes: 

Listing 9: Definition of the Configuration class 

1 // CD: Type of the coarse collision detection algorithm 

2 // FD : Type of the fine collision detection algorithm 

3 // BG : Type of the batch generation algorithm 

4 // CR: Type of the collision response algorithm 

e , typename FD 

7 , template <typename > class BG 

8 , template <typename , typename , typename > class CR > 

9 struct Configuration 

o { /* ... */ >; 

2 typedef Conf iguration < pe_C0 ARSE.COLLISI ON.DETECTOR 

3 , pe_FINE_COLLISION_DETECTOR 

4 , pe.BATCH. GENERATOR 

5 , pe_CONTACT_SOLVER 

e > Config; 


Listing 10 shows an excerpt of the actual realization of the Sandwich Pattern within the pe framework 
by means of the RigidBody base class and the therefrom derived Sphere class: 


Listing 10: Application to the Sandwich Pattern to the RigidBody class hierarchy 


i class RigidBodyBase 



// The total mass of the rigid body 
// The global position of the center of mass 
// The linear velocity of this rigid body 
// Angular velocity of this rigid body 


of this rigid body 


0 public : 

1 inline real 

2 inline const Vec3& 

3 inline const Vec3& 

4 inline const Vec3 & 

5 II ... 


getMassO const { 
getPositionO const { 
getLinearVelO const { 
get AngularVel () const { 



is template < typename C > 

19 class RigidBodyTrait : public RigidBodyBase 

20 { 

21 public : 

22 n ... 

23 virtual void move ( real dt ) = 0 ; 


26 class RigidBody : public RigidBodyTrait <Conf ig > 

27 { 

29 RigidBody* sb_ ; II The super ordinate rigid body 

30 II ... 

32 public : 

33 II ... 


37 t P P § y 

38 private: 

40 // . .. 

42 public : 

43 inline real getRadiusQ const { return radius.; > 

44 II ... 


47 template < typename C > 

48 class SphereTrait : public SphereBase 

49 { 

so public: 

51 II ... 

52 virtual void move ( real dt ) { /* Spher e - spec if i c implementation */ > 

53 II ... 


56 class Sphere : public SphereTrait <Conf ig > 

57 { 

59 II ... 

62 V // ... 

63 friend Sphere* createSphere ( size.t uid , const Vec3& gpos , real radius, 

64 MateriallD material, bool visible ); 


In contrast to the abstractions of the previous sections, in this example certain parts of the implemen- 
tation are shown to demonstrate the use of the Sandwich pattern. The RigidBodyBase class contains 
numerous common data members, as for instance the mass, the global position, the linear and angular 


velocity of a rigid body, along with the necessary functionality to access those values. These values are 
common to all rigid bodies and are independent of the functionality contained in the customizable func- 
tionality in the next class of the inheritance hierarchy. The RigidBodyTrait class, which inherits all these 
common characteristics, declares the move function that is as default used to move rigid bodies accord- 
ing to their current velocity and the acting forces for a time interval of dt. The RigidBody class, that 
publicly derives from the RigidBodyTrait instance for the current configuration, only contains common 
functionality that cannot be moved to the RigidBodyBase class. For instance, it contains a handle to a 
superordinate rigid body of type RigidBody*, which refers to a body that may contain this particular 
rigid body. 

SphereBase represents the base class for a spherical primitive and as such defines the necessary geo- 
metric information (in this case the radius of the sphere) along with the according access function. The 
SphereTrait class template implements the move function that was introduced by the according trait 
class of RigidBody for spherical primitives. On the top-level of the hierarchy, the Sphere class provides 
access for the according sphere setup function. 

Depending on the selection of the algorithms (see Listing 8), the according specialization of the trait 
classes is selected. In case of the FFDSolver, the move function does not suit the requirements and a 
slightly different behavior is required (for more information see [3]). Therefore a specialization is created, 
which defines a different set of virtual functions: 

Listing 11: Specialization of trait classes for the FFDSolver 

1 // CD: Type of the coarse collision detection algorithm 

2 // FD : Type of the fine collision detection algorithm 

3 // BG: Type of the batch generation algorithm 

4 // C : Type of the configuration 



class RigidBodyTrait < C<CD , FD , BG , response :: FFDSolver > > : public RigidBodyBase 
{ 

public: 

II ... 

virtual void f ir stPosit ionHalf St ep ( real dt ) = 0 ; 
virtual void secondPositionhalf Step ( real dt ) = 0 ; 

II ... 


n ... 

II CD: Type of the coarse collision detection algorithm 
II FD: Type of the fine collision detection algorithm 
II BG : Type of the batch generation algorithm 
II C : Type of the configuration 
template < template <typename > class CD 



public: 

II ... 

virtual void f irstPos it ionHalf St ep ( real dt ) { /* Sphere - spec if ic implementation */ > 
virtual void secondPositionhalf Step ( real dt ) { /* Sphere - spec if ic implementation */ > 
// ... 


In the according specializations of the RigidBodyTrait and the SphereTrait class, the move function is 
completely replaced by the two functions f irstPositionHalfStep and secondPositionHalf Step, which 


perfectly suit the requirements of the FFDSolver. Please note that only due to the application of the 
Sandwich pattern we are able to replace a single virtual function with two virtual functions. Therefore 
the data structures are nicely adapted to the compile time selection of the applied algorithms. 


5 Conclusion 

In this report, we have introduced the C++ design pattern called “Sandwich Pattern”. Via this pattern 
it is possible to statically replace a specific set of static and dynamic characteristics of a data type while 
leaving certain other characteristics untouched. We have demonstrated the application of this design 
pattern by means of an extended example of the pe physics engine, where rigid bodies are statically 
adapted to a compile time selection of algorithms working on these rigid bodies. 
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